Improve UX querying rpc for blocks at or before the snapshot from boot #23403
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
When an RPC node not backed by bigtable boots from a snapshot and fresh ledger, it initially reports
null
forgetBlock
requests for all slots <= snapshot slot + 1. This is because:Blockstore::lowest_cleanup_slot
reports 0. This is the field that RPC checks for theRpcCustomError::BlockCleanedUp
error, so it doesn't know that the snapshot slot and older slots aren't available. This persists until the first ledger prune occurs.Summary of Changes
Blockstore::get_first_available_block
to be root at index 1, instead of index 0, so that the value reflects the first completely available blockJsonRpcRequestProcessor::check_slot_cleaned_up()
and returnRpcCustomError::BlockCleanedUp
when older blocks are queried. This new case needs to cover both Err and Ok cases to handleBlockstore::get_complete_block
andBlockstore::get_block_time
responses, respectively. Regarding the error message: technically these blocks haven't been cleaned up... they never existed on this node. But this seems most consistent with the spirit of the error to me, and less confusing than it would be to have the error message change after the first prune.Note: these changes do not affect nodes with bigtable backing, since all methods query bigtable and return early before reaching
check_slot_cleaned_up()